A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

###1. What happens (in broad terms) if sys_remove is called on a file that is currently open by another running process? Will a read on the file by the second process succeed? A write? Why or why not? (1 point)

sys_remove removes the inode of the file from the file system. The processes that have a reference to the file will retain that reference and will be able to call read/write on that file and succeed. Processes trying to open the flie after sys_remove will not be allowed to do so. The file is purges from the filesystem after all open file descriptors fo that file have been closed.

###2. Describe the control flow, starting in the system call layer and proceeding through the VFS layer to reach SFS, that occurs for each of the following system calls. You need only trace the names of the functions that are called. Feel free to skip secondary or minor code paths that don't lead into SFS. (1 point)

###3. Now similarly describe the control flow within SFS for each of the same oper

I’ve written a newer optimized 2026 version of this guide with a faster setup using Zinit + Starship and improved plugin loading.

This version avoids slow shell startups and works better with modern Zsh setups.

Updated guide: https://gist.github.com/n1snt/2cccc8aa5f7b645a7628d3512c70deb6

A complete guide to building a Claude Code status line that shows your 5-hour and weekly usage limits with color-coded pacing, reset times, and context window usage — all from data Claude Code already provides via stdin.

What you get:

your-project │ ctx 0% │ 5hr (3pm) 16/65% │ wk (fri,12pm) 44/57% │ Opus 4.6 (1M context)

Solveit is a "Dialog Engineering" web application for interactive development. Unlike ChatGPT (pure chat) or Jupyter (pure code), Solveit combines three message types in one workspace: code execution, markdown notes, and AI prompts. Users build solutions incrementally—writing a few lines, understanding them, then continuing—rather than generating large code blocks.

The AI sees the full dialog context (code, outputs, notes, prompts) when responding -- but only those ABOVE the current message. Users can edit any message at any time, including AI responses—the dialog is a living document, not an append-only log.

The dialog is a running ipykernel instance. A "dialog" is like a "Jupyter notebook", and uses a compatible ipynb file format, but provides a superset of functionality (in particular, "prompt messages"). A "message" is like a "Jupyter cell", with additional attributes stored as ipynb cell metadata. Most standard jupyter functionality is supported (including cell